合适原则、简单原则、演化原则,架构设计时遵循这几个原则,有助于做出最好的选择。
合适原则
“合适优于业界领先”
大公司的分工比较细,一个小系统可能就是一个小组负责,比如说某个通信大厂,做一个OM管理系统就有十几个人,阿里的中间件团队有几十个人,而大部分公司,整个研发团队可能就100多人,某个业务团队可能就十几个人。十几个人的团队,想做几十个人的团队的事情,而且还要做得更好,不能说绝对不可能,但难度是可想而知的。
业界领先的很多方案,其实并不是一堆天才某个时期灵机一动,然后加班加点就做出来的,而是经过几年时间的发展才逐步完善和初具规模的。
更多的时候,“业务”发展到一定阶段,量变导致了质变,出现了新的问题,已有的方式已经不能应对这些问题,需要用一种新的方案来解决,通过创新和尝试,才有了业界领先的方案。
简单原则
“简单优于复杂”
软件领域的复杂性体现在两个方面:
1.结构的复杂性
结构复杂的系统几乎毫无例外具备两个特点:
组成复杂系统的组件数量更多;
同时这些组件之间的关系也更加复杂。
2.逻辑的复杂性
意识到结构的复杂性后,我们的第一反应可能就是“降低组件数量”,毕竟组件数量越少,系统结构越简。最简单的结构当然就是整个系统只有一个组件,即系统本身,所有的功能和逻辑都在这一个组件中实现。
不幸的是,这样做是行不通的,原因在于除了结构的复杂性,还有逻辑的复杂性,即如果某个组件的逻辑太复杂,一样会带来各种问题。
逻辑复杂的组件,一个典型特征就是单个组件承担了太多的功能。以电商业务为例,常见的功能有:商品管理、商品搜索、商品展示、订单管理、用户管理、支付、发货、客服……把这些功能全部在一个组件中实现,就是典型的逻辑复杂性。
功能复杂的组件,另外一个典型特征就是采用了复杂的算法。复杂算法导致的问题主要是难以理解,进而导致难以实现、难以修改,并且出了问题难以快速解决。
以ZooKeeper为例,ZooKeeper本身的功能主要就是选举,为了实现分布式下的选举,采用了ZAB协议,所以ZooKeeper功能虽然相对简单,但系统实现却比较复杂。相比之下,etcd就要简单一些,因为etcd采用的是Raft算法,相比ZAB协议,Raft算法更加容易理解,更加容易实现。
演化原则
“演化优于一步到位”
软件架构从字面意思理解和建筑结构非常类似,事实上“架构”这个词就是建筑领域的专业名词,维基百科对“软件架构”的定义中有一段话描述了这种相似性:
对于建筑来说,永恒是主题;而对于软件来说,变化才是主题。
考虑到软件架构需要根据业务发展不断变化这个本质特点,软件架构设计其实更加类似于大自然“设计”一个生物,通过演化让生物适应环境,逐步变得更加强大: 首先,生物要适应当时的环境。
其次,生物需要不断地繁殖,将有利的基因传递下去,将不利的基因剔除或者修复。
第三,当环境变化时,生物要能够快速改变以适应环境变化;如果生物无法调整就被自然淘汰;新的生物会保留一部分原来被淘汰生物的基因。软件架构设计同样是类似的过程:
首先,设计出来的架构要满足当时的业务需要。
其次,架构要不断地在实际应用过程中迭代,保留优秀的设计,修复有缺陷的设计,改正错误的设计,去掉无用的设计,使得架构逐渐完善。
第三,当业务发生变化时,架构要扩展、重构,甚至重写;代码也许会重写,但有价值的经验、教训、逻辑、设计等(类似生物体内的基因)却可以在新架构中延续。